1. SPP 單一職責原則：一個模組應只對唯一的一個角色負責

1. 以角色為模組凝聚的核心
2. 角色定義，因為相同時刻和原因，受到變動，視為同一同一個角色
3. 在參與讀書會的過程中，我們有深入討論，怎麼樣該視為同一個角色，我自己的結論是，在設計的當下，或者可預期的未來，使用模組的人，都會因為在相同時刻和目的，使用者模組中的方法，那麼視為同一個角色，即使他們如書中說明，他們屬於不同部門，理由是沒有一步到位的設計，且永不變動的需求，所以時候到的時候，再來更改就好了，架構是隨著時間演化的

2. 凝聚是種力量，將程式碼綁定在一起，用來對角色負責

1. 把相同相關的程式碼收攏再一起，或是把因為會有相同變動的程式碼歸納在一起，我一開始想到的是內聚性，書中提到這樣的好處是，避免為了類似的需求，碎片化的到處修改，此外也避免重複部署的成本，而我的理解是，至少對我最直接的幫助是，我知道要修改某需求，我只要到特定模組去就可以了，好變更，易維護

3.不遵守SRP 風險

1. 意外重複 ｜多角色共用method ，造成互相牽制影響
   • 書中提到的例子是HR系統，同時有三種角色在使用HR & 財務，他們共用計算加班薪資的方法，但萬一政府要修改加班認定的規則，那麼工程師修改加班薪資的方式，就會造兩個角色的衝突
2. 合併修改｜共同編輯一個類別，導致合併了修改
   • 同上例子，簡單說就是兩個人改了同一份檔案，造成檔案合併修改，引發災難

解決辦法

1. 將類別根據角色做拆分小類別

   • 這是回歸到最根本問題，究竟你的類別使用者是誰？他們使用方法的時機為何
   • Employ class → PayCalculator class & HourReporter class

2. Facade 模式

   • 什麼是 Facade ?
     1. Facade 只負責實例化和委託具有函式的類別
     2. 用手洗衣服故事，來說明Facade模式
        • 假設今天你要手洗衣服，你要做一系列動作，拿個桶子→放水→放洗衣精→浸泡衣服→用手搓揉→擰乾，想像每一個動作都需要調用一個類別的方法，光是手洗衣服這件事，就需要調用六個類別．
        • 假設今天走到自動洗衣機，你只需要丟衣服，按下洗衣服，done! ，洗衣機自動幫你放水，浸泡，搓揉，脫水，你不需要知道洗衣機怎麼做到的，你只需要呼叫洗衣機類別，然後使用它的方法，這個方法就幫你把以上不同類別的方法調用完畢

參考

Facade 門面模式